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IN THE UNITED STATES PATENT AND TRADEMARK OFFICE 

In re Application of: ) 
MICHAEL WEIL AND et al. ) 

Serial No. 10/620,732 ) 

Title: METHOD OF REPRESENTING ) 
ROAD LANES ) 

Filed: July 16, 2003 ) 

DECLARATION UNDER 37 CFR 1.131 

The undersigned, MICHAEL WEILAND, GREGORY NYCZAK, WILLIAM 

Mcdonough, michael tsengouras, david shuman, and paul ford, 

each hereby declare that: 

1 . We are co-inventors of the invention described and claimed in the above- 
identified patent application. 

2. Before May 15, 2003, as part of a project entitled "EDMap", we invented 
a new data model for representing road lanes in a database. Part of this new data model 
included adding new information to the data representation of a physical road lane 
including, but not limited to, (i) data that indicates the start and end points of the 
represented physical road lane, and (ii) data that indicates what physical features are 
adjacent to and extend along the represented physical road lane on the right and left sides. 

3. Before May 15, 2003, we prepared an Invention Disclosure Statement 
Form describing our invention. We filed the Invention Disclosure Statement Form with 
the Legal Department of the assignee of the subject patent application. A redacted copy 
of the Invention Disclosure Statement is attached hereto. 

4. The third and fifth bullet points in the section entitled "Detailed 
Description of Invention" on page 2 of the attached Invention Disclosure Information 
Form disclose the elements of our invention recited in paragraph 2., above. 



Page 1 of 2 



Serial No. 10/620,732 

5. All statements made herein of my own knowledge are true and that all 
statements made on information and belief are believed to be true, and further these 
statements are made with the knowledge that willful false statements and the like so made 
are punishable by fine or imprisonment, or both, under Section 1001 of Title 18 of the 
United States Code, and that such willful statements may jeopardize the validity of the 
application or any patent issuing thereon. 



MICHAEL WEIL AND DATE 
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NAVIGATION TECHNOLOGIES CORPORATION 
INVENTION DISCLOSURE STATEMENT FORM 

(Return electronic copy and 
fully executed hard copy to Legal Department) 



IDS# 



(to be filled out by Legal Dept.) 



Shorthand Name for Invention: Method for Modeling Road Networks at Lane Level 
Developers Who Contributed to Invention: 



1. 
3. 
5. 
7. 



Michael Weiland 
Mac McDonough 
Dave Shuman 



Greg Nyczak 
Michael Tsengouras 
Paul Ford 



Date (or Month) on Which Development Began: 




If Known, First Date (if any) on Which Development was: 




(a) described in a CONFIDENTIAL document released outside of NTC 




(b) described in a CONFIDENTIAL conversation with a non-NTC employee 




(c) described in a NON-confidential document released outside of NTC 




(d) described in a NON-confidential conversation with a non-NTC employee 




(e) included in any version of a product released outside of NTC 




(0 used internally at NTC in the normal course of operations: 




(g) discussed at a Brainstorming Session for IDS No, 




Summary of Invention: 



Some future ADAS-type applications require information about the geometry of individual lanes on a roadway, in addition to 
road centerlines. Existing NTC conventions for how roads change and intersect one another do not necessarily translate well 
into a lane-by-lane model. This EDS discusses the issues that are present regarding a lane-level database, and approaches being 
taken to address these issues. 



Key Words for Invention: 



Lane geometry, transition lanes, ADAS 



Advantages of Invention (to the extent known): 



A lane-level database enables a number of ADAS applications that would not be able to function without this level of detail. 
A lane departure warning system is straightforward example. A forward collision warning is less obvious, but this type of 
system needs to determine whether an object detected ahead of the vehicle is inside or outside the vehicle's lane. 

Introducing lane-level geometry requires a number of problems to be solved which are not present in a basic road-level 
database. 

• There is typically (but not always) lateral connectivity between parallel lanes which must be modeled. There will not 
be any particular points at which traffic can change from one lane to another, and the path taken be vehicles to effect 
lane changes will vary, depending on driver preference and typically influenced by speed and traffic conditions. 

• Lanes can begin or end in the middle of a roadway, causing vehicle paths to move into or out of lanes. In the 
transitional areas where lanes begin or end, the physical centerline of the narrowing/widening lane will not 
correspond to a likely vehicle path. The vehicle paths of cars entering or leaving these lanes is not expected to be 
precisely predictable. 

• Lane-specific attributes may change at any longitudinal point along a lane. Different lanes along a road may have 
attribute change at different longitudinal points. 

• Geometry as traditionally represented (shape points interpolated by straight line segments, also known as a 
"polyline") will not have sufficient curve smoothness for lane-level ADAS applications. 
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• At intersections, the crossings between every lane would imply connectivity between crossing lanes that is not 
present in reality, or if the connectivity exists, in the wrong place. 

• To support compatibility with road-level maps and applications, lane data must be associated with road links. 

• It must be possible to create lane-level data reliably from practical source materials. These materials include vehicle 
path data from driving, overhead aerial imagery, and probe vehicle ("floating car") data. 

Developed for the ADAS "EDMap" project, the lane-level data model described here (together with the related intersection 
data model) addresses and solve these problems. 

Detailed Description of Invention 

• describe function(s) performed 

• describe with particularity the way in which each function is achieved (e.g., if the invention is a 
process, describe each step of the process): 

The key elements of the lane-level data model are: 

• A lane centerline is defined for every portion of a road lane where both edges are discernable and the lane is at full 
width. The centerline is defined as the line midway between the lane edges. Lane edges can be lane markings (such 
as paint) and/or physical edges (such as a curb, median or edge of pavement). Having well-defined criteria for what 
is and is not a lane helps make the data creation process more reliable and reproducible. 

• The actual geometry of a lane can be expressed as parametric curvature (such as a uniform B-spline, non-uniform 
B-spline, or clothoid) or as a set of shape points interpolated by straight line segments (a "polyline"). This enables 
better -behaved curvature as demanded by ADAS applications. 

• Where a lane is starting or ending, i.e., the lane is widening to or narrowing from its full width, no lane centerline is 
provided. Rather, the adjacent lane(s) will be attributed to indicate that a lane is starting or ending. This definition is 
compatible with the lack of reliable vehicle paths for cars entering or leaving the lane that is forming or ending. 

• Attributes can be applied to a longitudinal subset of a lane (defined as a "sublane"). The sublane is defined by a pair 
of points along the lane, expressed as distances along the lane curve from a designated end. The sublane has no 
geometry of its own. This allows attributes to begin and end as necessary along a lane, without complicating the 
underlying lane's geometry. 

• Each lane will have a pair of "adjacency" attributes, indicating what lies to the left and right of the lane. This 
attribute can be applied to the whole lane and also to a longitudinal subset of the lane (a "sublane"). This adjacency 
can be any of: 

o Another lane, which can be entered by a lane change 
o Another lane but which cannot be entered 
o A lane is in the process of forming 
o A lane is in the process of ending 
o A shoulder 

o Another "drivable surface" (not a lane or shoulder, but might have a vehicle on it, such as a parking lane or 
low median) 

o No drivable surface (a drop-off, a barrier, etc.) 
This adjacency attribute addresses the problem of lateral lane changes by defining where such changes can legally 
occur, and further defines for applications places where other vehicles are likely to be present. 

• Lanes will not cross one another. A lane goes up to, but not through, the intersection at the end of the road link. This 
prevents any implied connectivity between lanes that is not consistent with reality. 

• In the case of bifurcations (a true "lane split"), two lanes can be modeled such that their centerlines start at the same 
point. These will be attribute as "overlapping" to indicate that two lane surfaces share some of the same pavement. 

• A lane will not extend beyond the end of the road to which it belongs. A physical lane may continue unbroken 
across multiple road links, such as when a ramp splits off from (one lane of) the road, but each road's lanes will be 
modeled separately. Each lane is associated with exactly one road link. This will ensure compatibility with the 
existing NAVTECH link-based data model 



Please check the appropriate box: 

Rev. 01/09/01 
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No design documents exist 

The following design documents exist (and copies are attached): 
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Signatu 

(of preparer-developer) 
Type Name: Michael Weiland 
Signature(s) of ContribifQng'pey^lppers: 

1. Name:, 

2. Name:. 

3. Namey£ 

4. Name: 

5. Name: 




6. Name:. 

7. Name:. 



Date: 
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PATENT 
Case No. N0169US 

IN THE UNITED STATES PATENT AND TRADEMARK OFFICE 

in re Application oil ) 
MICHAEL WETLAND ei at. j 

) 

Serial No: 10/62.0,732 ) 

) 

Title: METHOD OF REPRESENTENG ) 
ROAD LANE'S ) 

) 

Filed: July 16,2003 ) 

DECLARATION UNDER 37 CFR 1.131 

The undersigned, MICHAEL WETLAND, GREGORY NYCZAK, WILLIAM. 

Mcdonough, michael tsengouras, david shuman, and paul ford, 

each hereby declare that: 

1. We are. co- inventors of the invention described, and claimed in the above- 
identified patent .application. 

2. Before May 15, 2003. as part of a project entitled "ED Map", we invented 
a new data model for representing road: lanes in i database. Part of this, new data model 
included adding new imorrnation to the data replantation of a physical road Eane 
including, bat not limited to, (i) data thai indicates, the start and end points ofthe 
represented physical road, jane, and (ii) data thai indicates what physical features are 
adjacent io and extend along the represented physical road lane on the light and left sides, 

3: Before May 1$, 2003,. we prepared an invention Disclosure Statement 
Form describing our invention. We filed die Invention Disclosure Statement Form with 
the Legal Department of the assignee of the. subject patent application. A redacted copy 
ofthe Invention Disclosure Sta.tem.eni is attached hvreto. 

4. The third and itfth bullei points in. the section entitled "Deuriied 
Description of invention" oil page 2 of the attached Invention Disclosure Iriiormation 
Form disclose the elements of our invention recited in paragraph above; 
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5. AM. statements made herein of my own knowledge are true and thaiaU 
statements made oiiinibrojaiion and belief are believed to. be true, and further these 
statements are made with the knowledge that willful false statements and die like so made 
.are punishable 1 by fine or imprisotmtem.or both, under Section 1001 ofTiile IS ofthe 
United States Code, and that such willful statements may jeopardize the validity of the 
application or.any patent issuing thereon. 



MICHAEL WEILAND 



DATE 



GREGORY NYC2AK 



DATE 



WILLIAM McDONQUCjR 



DATE 



MICHAEL TSENQQURAS 

_____ Sftu ^— : 



DATE 



DATE 



PAUL FORD 



DATE 
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fully executed hard copy to Legal Department) 
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(to be filled out by Legal Dept) 



Shorthand Name for Invention: Method for Modeling Road Networks at Lane Level 
Developers Who Contributed to Invention 



1. 
3. 
S. 
7. 



Michael Weiland 
Mac McDonough 
Dave Shuman 



2. 
4. 
6. 
8. 



Greg Nvczak 
Michael Tsengouras 
Paul Ford 



Date (or Month) on Which Development Began: 




If Known, First Date (if any) on Which Development was: 




(a) described in a CONFIDENTIAL document released outside of NTC 




(b) described in a CONFIDENTIAL conversation with a non-NTC employee 




(c) described in a NON-confidential document released outside of NTC 




(d) described in a NON-confidential conversation with a non-NTC employee 




(e) included in any version of a product released outside of NTC 




(f) used internally at NTC in the normal course of operations: 




(g) discussed at a Brainstorming Session for IDS No. 





Summary of Invention: 

Some future AD AS-type applications require information about the geometry of individual lanes on a roadway, in addition to 
road centerlines. Existing NTC conventions for how roads change and intersect one another do not necessarily translate well 
into a lane-by-lane model. This IDS discusses the issues that are present regarding a lane-level database, and approaches being 
taken to address these issues. 



Key Words for Invention: 

Lane geometry, transition lanes, ADAS 

Advantages of Invention (to the extent known): 

A lane-level database enables a number of ADAS applications that would not be able to function without this level of detail. 
A lane departure warning system is straightforward example. A forward collision warning is less obvious, but this type of 
system needs to determine whether an object detected ahead of the vehicle is inside or outside the vehicle's lane. 

Introducing lane-level geometry requires a number of problems to be solved which are not present in a basic road-level 
database. 

• There is typically (but not always) lateral connectivity between parallel lanes which must be modeled. There will not 
be any particular points at which traffic can change from one lane to another, and the path taken be vehicles to effect 
lane changes will vary, depending on driver preference and typically influenced by speed and traffic conditions. 

• Lanes can begin or end in the middle of a roadway, causing vehicle paths to move into or out of lanes. In the 
transitional areas where lanes begin or end, the physical centerline of the narrowing/ widening lane will not 
correspond to a likely vehicle path. The vehicle paths of cars entering or leaving these lanes is not expected to be 
precisely predictable. 

• Lane-specific attributes may change at any longitudinal point along a lane. Different lanes along a road may have 
attribute change at different longitudinal points. 

• Geometry as traditionally represented (shape points interpolated by straight line segments, also known as a 
"polyline") will not have sufficient curve smoothness for lane-level ADAS applications. 




• At intersections, the crossings between every lane would imply connectivity between crossing lanes that is not 
present in reality, or if the connectivity exists, in the wrong place. 

• To support compatibility with road-level maps and applications, lane data must be associated with road links. 

• It must be possible to create lane-level data reliably from practical source materials. These materials include vehicle 
path data from driving, overhead aerial imagery, and probe vehicle ("floating car") data. 

Developed for the ADAS "EDMap" project, the lane-level data model described here (together with the related intersection 
data model) addresses and solve these problems. 

Detailed Description of Invention 

• describe function(s) performed 

• describe with particularity the way in which each function is achieved (e.g., if the invention is a 
process, describe each step of the process): 

The key elements of the lane-level data model are: 

• A lane centerline is defined for every portion of a road lane where both edges are discernable and the lane is at full 
width. The centerline is defined as the line midway between the lane edges. Lane edges can be lane markings (such 
as paint) and/or physical edges (such as a curb, median or edge of pavement). Having well-defined criteria for what 
is and is not a lane helps make the data creation process more reliable and reproducible, 

• The actual geometry of a lane can be expressed as parametric curvature (such as a uniform B-spline, non-uniform 
B-spline, or ciothoid) or as a set of shape points interpolated by straight line segments (a "polyline "). This enables 
better-behaved curvature as demanded by ADAS applications. 

• Where a lane is starting or ending, i.e., the lane is widening to or narrowing from its full width, no lane centerline is 
provided. Rather, the adjacent lane(s) will be attributed to indicate that a lane is starting or ending. This definition is 
compatible with the lack of reliable vehicle paths for cars entering or leaving the lane that is forming or ending. 

• Attributes can be applied to a longitudinal subset of a lane (defined as a "sublane"). The sublane is defined by a pair 
of points along the lane, expressed as distances along the lane curve from a designated end. The sublane has no 
geometry of its own. This allows attributes to begin and end as necessary along a lane, without complicating the 
underlying lane's geometry. 

I • Each lane will have a pair of "adjacency" attributes, indicating what lies to the left and right of the lane. This 

attribute can be applied to the whole lane and also to a longitudinal subset of the lane (a "sublane"). This adjacency 
can be any of: 

o Another lane, which can be entered by a lane change 
o Another lane but which cannot be entered 
o A lane is in the process of forming 
o A lane is in the process of ending 
o A shoulder 

o Another "drivable surface" (not a lane or shoulder, but might have a vehicle on it, such as a parking lane or 
low median) 

o No drivable surface (a drop-off, a barrier, etc.) 
This adjacency attribute addresses the problem of lateral lane changes by defining where such changes can legally 
occur, and further defines for applications places where other vehicles are likely to be present. 

• Lanes will not cross one another. A lane goes up to, but not through, the intersection at the end of the road link. This 
prevents any implied connectivity between lanes that is not consistent with reality. 

• In the case of bifurcations (a true "lane split"), two lanes can be modeled such that their centerlines start at the same 
point. These will be attribute as "overlapping" to indicate that two lane surfaces share some of the same pavement. 

• A lane will not extend beyond the end of the road to which it belongs. A physical lane may continue unbroken 
across multiple road links, such as when a ramp splits off from (one lane of) the road, but each road's lanes will be 
modeled separately. Each lane is associated with exactly one road link. This will ensure compatibility with the 
existing NAVTECH link- based data model. 



Please check the appropriate box: 

Rev. 01/09/01 
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No design documents exist 

The following design documents exist (and copies are attached): 
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(of preparer-developer) 
Type Name: Michael Weiland 
Signature(s) of Contribi^ng^peyf I^ers: 
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